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Abstract. Abstract. Design by Constract (DBC) has influenced the de- 
velopment of formal specification languages that allow the mix of spec- 
ification and implementation code, like Eiffel, the Java Modeling Lan- 
guage (JML) and Spec#. Meanwhile algebraic specification languages 
have been developing independently and offer full support for specifica- 
tion and verification of design for large and complex systems in a math- 
ematical rigorous way. However there is no guarantee that the final im- 
plementation will comply to the specification. In this paper we proposed 
the use of the latter for the specification and verification of the systems 
design and then by presenting a translation between the two, the use of 
the former to ensure that the implementation respects the specification 
and thus enjoy the verified properties. 

Keywords: CafeOBJ, JML, Observational Transition Systems, Design 
by Contract, Behavioral Specifications, 



1 Introduction 

Over the last decade we are seeing an increased research interest towards for- 
mal Behavioral Interface Specification Languages (BISs), implementing Design 
by Contract (DBC), for languages such as Java and C#. What is even more 
encouraging is that major companies like Google and Microsoft are involved in 
the development of such languages (cofoja[28], spec#[30]). The basic concept in 
such languages is a contract. A contract specifies the obligations and require- 
ments of methods and method callers. Contracts are defined in the programming 
language itself and are translated into executable code by the compiler. Some of 



* This paper was supported by the THALIS project "Algebraic Modeling of 
Topological and Computational Structures and Applications". The Project THALIS 
is implemented under the Operational Project Education and Life Long Learning 
and is co-funded by the European Union (European Social Fund) and National 
Resources (ESPA). 



2 OTS2DBC 



these languages also provide a wide range of tools that implement either real- 
time assertion checks (RAC) or static verification tools (SV). Meanwhile the 
development of specification languages independent of a particular implement- 
ing language is continuing. Over the decades many such languages and theorem 
provers have been developed. They adopt much sounder mathematical bases and 
provide powerful theorem provers that are able to verify the most complex of 
properties. In addition they can use various levels of abstraction and specify 
and verify design. For example in the family of algebraic specification languages 
the research and applications of languages like OBJ, BOBJ, CafeOBJ, Maude 
etc. has been substantial. One could argue that either approach is better. From 
a programmers point of view it is preferable to have a specification language 
that is close to the programming language, that is easy to learn and can be used 
without having to learn difficult mathematical concepts. On the other hand from 
a design engineer or mathematician point of view the soundness of the theorem 
provers, the ability to reason about design and not implementation and so on 
is more important. In this paper we attempt to combine the two approaches 
and hopefully adopt the strengths of both while overcoming some of their weak- 
nesses. In a nutshell we propose that the specifications are initially generated in 
an algebraic specification language capable of defining Observational Transitions 
Systems (OTS) specifications (like CafeOBJ). The desired system properties, be 
they safety or liveness, are proved with regard to this specification using the 
sound methods provided by this framework. Then this specification is translated 
into a DBC specification language, like the Java Modeling Language (JML). Fi- 
nally the programmer can create the implementation based on the JML contracts 
and the JML compiler checks whether the implementation satisfies the specifi- 
cation either during run-time or statically. The choice of JML is due to purely 
historical reasons, since the features required can be found in most modern DBC 
languages for Java such as modern Jass [29] etc. The OTS/CafcOBJ method was 
chosen because concepts like inheritance, the use of multiple objects/systems etc. 
are defined naturally here] . 



1.1 Related Work 



Predating our work here, are [16, 17, 18 and 29]. In [16] the authors propose 
an automatic translation from CafeOBJ specifications to Java template code 
(which contains only the signatures of methods the class needs etc.). In [17] 
they go a step further to generate automated code for the behavioral part of 
the specification. But as they state because an OTS/CafeOBJ specification is 
a state based specification, the output of this automated translation may not 
be a suitable statement for the method we are trying to implement in Java. In 
[18] the authors provide design notations of an OTS specification implemented 
in CafeOBJ (Mcta-OTS/CafeOBJ) and an OTS implemented in Java (Meta- 
Java/CafeOBJ), then they provide a specification of the translation rules from 
Meta-OTS/CafeOBJ to Meta-Java/CafeOBJ in CafeOBJ. This allows them to 
finally verify the correctness of the translation. The work in [29] is the closest to 
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ours. The authors see B-machines as the most suitable language for the specifi- 
cation of Java programs and present an automated translation from B-machines 
to JML. This approach is very close to what we propose here, the main difference 
is that we believe OTS/CafeOBJ specifications are better suited for the specifi- 
cation of Object-orientated systems due to their natural support for inheritance, 
the use of multiple objects and so on, features that are not supported at the 
moment in [29]. 

1.2 Contribution 

The contribution of this work as far as CafcOB J is concerned lies in the fact that 
using the proposed methodology we can create an implementation (in Java) of 
an OTS/CafeOBJ specification that satisfies it. CafcOBJ is independent from 
the choice of a particular implementation language. This is both a strength, gen- 
erality of the method and so on, but at the same time is a weakness because 
it provides no guarantee that the implementer will conform to the specification 
so that properties that were proved will still hold by the implementation. By 
defining a formal translation to JML we can guarantee the production of Java 
code that conforms to the CafeOBJ specification, and consequently holds the 
same properties (there are tools to check that the Java code written by the pro- 
grammer satisfies the JML specification). We believe this is better than a direct 
translation to the implementing language. This way the designer can handle 
the design issues without getting into unnecessary implementation/optimization 
details that might not be easy to express in a specification language. 

One could argue why not only use JML then or some other DBC language 
for Java? An important downside of JML is the lack of support for the current 
version of Java. Other DBC for Java languages like Cofoja and modern Jass 
support Java 7, however they lack the verification tools. Also, while Java has 
proven its power, no language is perfect. So it might be beneficial to use different 
languages for different parts of the implementation. By only using JML it is not 
possible to reason about parts of the system that are not implemented in Java. 
By specifying in a more general and abstract language such as OTS/CafeOBJ 
we can reason about the design of the whole system and its properties and then 
implement the components in the appropriate language such as Java or C#. Of 
course there should be such translations from OTS/CafeOBJ to say spec# in 
order to use C#, but these translations are left for the future. 

Secondary to the above, our approach provides a way to minimize specifica- 
tion. Only a small subset of the implementation has to be specified, the meth- 
ods/classes that correspond to the OTS/CafeOBJ specification. For the rest of 
the implementation the only restriction is that the extra methods/objects have 
to be called/used from within contracted methods. In addition the proofs in 
the OTS/CafeOBJ method are computer human interactive. As a result when 
a proof fails it conveys information as to why that happened, this can result in 
the redesign to the system and a deeper understanding of the problem at hand. 
Closing, a key feature of this approach is the reusability of proofs as well as 
specifications. Objects are combined in ways that preserve their properties, so 
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it will be easy to create libraries of verified code, that can be used freely and 
reduce the time required to specify new systems. 

The rest of this paper is organized as follows. Section 2 gives an overview of 
related work. Section 3 introduces the reader to Design by Contract (DBC) and 
JML, section 4 presents some key elements of Observational Transition System 
(OTS), CafcOBJ and how OTSs are expressed with CafeOBJ terms. Section 5 
presents our mapping from OTS to JML/ Java. Section 6 the translation from 
OTS/CafeOBJ to JML/Java and the final section concludes the paper with some 
future goals. 

2 Short Introduction to JML 

Design by contract (DBC) is a method for developing object orientated software 
first proposed in 1992 in [4]. The corner stone of this approach is that the class's 
methods and the clients (programs) that invoke them have a so call contract 
between them. On the one hand the invokcr of a method guarantees certain 
pre-conditions before calling the method and on the other hand the method is 
able to guarantee that certain post-conditions will hold after its execution. The 
use of such pre and post conditions to specify the behavior of programs dates 
back to Hoare's paper [5] in 1969. The basic idea of this Hoare logic is that of a 
triplet P C Q where P and Q are assertions, (the pre and post-conditions) and 
C is a command of the program. The main contribution of DBC is that these 
contracts are executable, meaning that they are defined in the program code in 
the programming language and are translated into executable code by the com- 
piler. This makes it possible for any violation of the contracts that occur while 
the program is running to be detected immediately. JML is a formal Behavioral 
Interface Specification Language for Java [1] that can be used as a design by 
contract (DBC) tool for Java programs. A JML specification is created using 
special annotated comments, which start with the sign @. The specification of 
the obligations of the client is denoted by using the key words //@ requires and 
the methods post-conditions, that the implementer has to meet, are denoted 
using //©ensures. A contract in JML is a set of pre and post conditions for a 
method, such contracts can be used to as an abstraction of a methods behav- 
ior. As in Eiffel [6], JML uses Java's expression syntax to write the predicates 
that are used to express the assertions and pre and post conditions. The lack 
of expressiveness of the Java language to write formal specifications is solved by 
extending Java expressions with the required specification contracts, for example 
quantifiers [1]. In addition JML is designed to be used with a range of tools [7, 
8]. The range of these tools is from DBC support to runtime assertion checking 
and to verification of specifications using theorem provers [1] . The semantics of a 
JML method's specification is that when the method is invoked in a state where 
its pre-conditions are met, then one of the following two things will happen. 
Either the method terminates normally, in which case the post-conditions of the 
specification are guaranteed, or there method throws an exception, in which case 
the exception thrown must be permitted by the specification (either by default 
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or explicitly) and the exceptional post-conditions must be satisfied (these con- 
ditions are denoted by the signals clause) [1]. Invariants in JML are used as a 
way to reduce the size of a specification. An invariant is a JML property that 
must hold in all visible states that a method is invoked. Here a visible state 
is defined as the parts of the code where the method is invoked. Consequently 
these invariants must hold at the end of each constructor execution and at the 
beginning and end of all method invocations. The main difference between in- 
variants and pre, post-conditions is that invariants apply to all subtypes through 
specification inheritance, while predicates that appear in all pre, post-conditions 
are not inherited as part of the specification of any new methods that may 
be added through subtyping [2]. JML supports several kinds of quantifiers in 
assertions: universal quantifier (\forall), existential quantifier (\exists), gener- 
alized quantifiers (\sum, \product, \min and \max) and a numeric quantifier 
(\num_of) among others. Referring to the value of a field before the invoca- 
tion of the method is done using the old clause (\old). Extra constructs such 
as implies (==>), follows from (<==), if and only if arc defined as 

wclll [2] . Some of the more advanced notions for behavioral specification using 
JML include method Purity and Frame Properties, Datagroups, Model Fields 
and Ghost Fields. Due to the restriction of DBC, for having only side effect free 
methods as parts of the assertions of the contracts, only query methods can be 
used. This is defined in JML as method Purity and is declared using the keyword 
pure as an annotation before the name of the method [3] . By Frame properties 
we mean that any variables not mentioned in the specifications post-conditions 
should remain unchanged after the invocation of the method. In JML the as- 
sign clause in the contract specifies what parts of the system may change by 
this method [3]. Frame properties are restrictive in that since they cannot be 
extended through specification subtyping. To solve this JML uses datagroups. 
A datagroup is an abstract piece of an objects state that may be extended by 
future subclasses by simply stating what fields belong to it. To connect such 
an abstract field with a field of the implementation we use the JML represents 
clause. A datagroup is assigned to every model field so that we can use them 
in the assignable clauses. If we wish to provide additional state, which may or 
may not be related to the existing state we use a Ghost field. A ghost field is a 
specification only field that unlike the model field can be assigned a value inside 
the specification, throw the set construct [2]. 

The JML compiler (jmlc) is an extension to the Java compiler that compiles 
Java programs annotated with JML specifications into Java byte-code [1]. The 
compiler includes in the byte code run time assertion checking instructions. Using 
these instructions, it is possible to check the assertions of the specifications 
such as pre, post-conditions on run time [1]. This feature falls in the category 
of Runtime Assertion (RAC) tools. We must keep in mind however that the 
specification may be incorrect, but the code implementation consistent to it. Note 
that the assertion checker is transparent when no inconsistences occur. As stated 
in [2] one of the major advantages of the jmlc, over other runtime assertion tools 
like Eiffel and Jass, is that it supports abstract specifications written in JML in 
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public class Person { 

private /*@ nonjiull @* String name; 

private int weight; 

/*@ public invariant !name.equals("") @ kk weight >= 0; @*/ 

//@ ensures \result != null; 

public String getName() {return name; } 

//@ ensures \result == weight; 

public /*@ pure @*/ int getWeightQ {retrun weight; } 

/*@ requires kgs >= 0; 

@ requires weight + kgs >= 0; 

@ ensures weight == \old(weight + kgs); 

@*/ 

public void addKgs(int kgs) { weight = weight + kgs; } 

/*@ requires n != null kk !n.equals(""); 

@ ensures n.equals(name) 

@ kk weight == 0; @*/ 

public Person(String n) { 

name = n; }} 

Table 1. JML/Java Class example 



terms of model fields, ghost fields, and model methods. Any run time violation 
is reported by some error (this is the Eiffel approach [1]). But the tool support 
is not limited to RAC. Static verifications (SV) tools such as ESC/JAVA2 [3], 
are available that allow the verification that no violations of the verification will 
occur during run time using logical techniques. As analyzed in [3] these tools 
preform what is called extended static checking [fO, 11], compile time checking 
that goes well beyond type checking. In particular ESC/JAVA2 supports the full 
of JML and is capable of checking for inconstancies between the code and the 
JML annotations. ESC/JAVA2 is neither sound nor complete deliberately and 
uses a non- interactive theorem prover. Another similar tool is LOOP which can 
be used to verify JML annotated code [12], as the authors of [3] state it can be 
very labor intensive but it allows the verification of more complicated properties 
that cannot be check automatically by ESC/JAVA2. For similar intent tools such 
as JACK we refer you to [3] . Some of the more interesting properties in real life 
systems are the so called Safety and Liveness properties. A safety property states 
that something bad will never happen, while a liveness property states that 
something good eventually will happen. The former means that the system will 
never reach a state that a desired predicate does not hold, while the later that 
the system eventually will reach a state where the desired predicate holds. These 
types of properties are not easy to either specify or verify in JML. The author 
of [13] originally propose an extension of JML that allows the verification of 
such temporal properties called JTPL (Java Temporal Pattern Language) , then 
through the use of a tool called JAG (JML Annotation Generator) translate 
this back into JML annotations ensuring the correctness of the translation [14]. 
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Closing this section, we present a simple Java class annotated with JML, to give 
a first feel of the language. Assume we wish to specify that a class defining a 
person and that each such person object is required to have a valid name and 
a valid weight, also we desire that the new objects have a weight of zero. We 
also wish for this class to have methods that returns the weight of the person, 
his name and a method that allows us to add weight to him. Such a Java Class 
annotated with JML can be seen in tablel. 

3 Behavioral Specifications and Observational Transition 
Systems 

Hidden algebra is an approach for giving semantics particularly for concurrent 
distributed object orientated systems, as well as for software engineering in gen- 
eral [15]. This approach is based on equations rather than other formalisms, like 
higher order logic for example. The reason behind this decision is that the proofs 
supported by this calculus allow maximal simplicity of mechanization and at the 
same time this approach allows for adequate expressiveness [15]. Hidden algebra 
is a generalization of process algebra and transition systems that by including 
non-monadic operations, allows the use of equations that contain methods or 
attributes that are parameterized by data [15]. The key of this approach is the 
concept of behavioral satisfaction. This means that we focus on how systems 
behave in response to a given set of experiments and not on the implementation 
details of those systems. So here the state space of an object (system) is regarded 
as a kind of black box, where we can only observe the state of it by using these 
experiments, or attributes or observation operators as they are called. This is a 
version of behavioral type in the object oriented paradigm, but like the authors 
of [15] we will refer to it as behavioral specification. In the heart of this approach 
are the behavioral objects, that are used to model a system and we will infor- 
mally present here. As the author of [19] states, a behavioral object is simply a 
special case of behavioral specifications that formally specifies the state space of 
the system together with two set of operators on the state space. The set of ac- 
tions (or methods) that are capable of changing the state of the system and the 
set of observations (or attributes) that are the experiments mentioned before, 
operators who take as arguments instances of the state space and return data 
types, the result of the experiments. Informally two states of such a behavioral 
object are considered equal when all observers return the same values in those 
states. Also two behavioral objects are equivalent when there is an isomorphism 
between the implementations modulo, the same state space, the same actions, 
and the same behavioral equivalence between the states [19]. Behavioral objects 
defined in this manner allow for the definition of several types of composition 
operators on behavioral objects [19]. For extensive definitions of hidden alge- 
bra, behavioral specification, and behavioral object compositions we refer the 
interested reader to [15, 19] as they are outside of the scope of this paper. 

An Observation Transition System (OTS) is a transition system that can be 
written in terms of equations and is a proper sub-class of behavioral specifica- 



8 OTS2DBC 



tions. Assuming there exist a universal state space Y, and that each data type 
we wish to use is already defined in terms of initial algebra an OTS S is defined 
as the triplet S =<0,I,T >, where [20]: 

— O is a finite set of observers. Each o G O is a function o : Y — > D, where 
D is a data type and may differ from observer to observer. Given an OTS S 
and two states m, u 2 G Y the equivalence between them wrt. S is defined as 
Vo G 0,o(ui) =s o(u 2 ). 

— I: is the set of initial states for the system, i.e. ICY. 

— T: is finite set of transition functions. Each r G is a function r : Y — > Y, such 
that t{u\) = t(u 2 ) for each [u] G Y/ =s and ui,u 2 G [u]. t(u) is called the 
successor state of u with respect to S. Also with each r, comes a condition 
c — t, called the effective condition of r, such that r(u) =5 u if -c — t(m). 

Observers and transitions are usually parameterized, generally they are de- 
noted as Oi x ...i m and Tj 1 ...j n provided that there exist data types Dk and fc G 
{h, ■ --imji, ■ --jn} with m,n > 0. 

3.1 CafeOBJ in a nutshell 

CafeOB J is a formal specification language that is able to handle the verification 
of algebraic specifications through various techniques. These include the com- 
puter human interactive verification of safety properties [23] , liveness properties 
[24] and a framework for fully automated verification [25], finally support is 
provided for finding counter examples [26]. These techniques have been heavily 
applied for the verification of a plethora of real life systems in many different 
fields. CafeOBJ is based on multiple logical foundations but mainly on initial 
and hidden algebras [21]. Static aspects of systems are specified in terms of initial 
algebras and dynamic aspects are specified in terms of hidden algebras. CafeOBJ 
incorporates observational (behavioral) specifications. The basic building blocks 
of all CafeOBJ specifications are modules. The keyword mod*, denotes the be- 
ginning of a module, with loose semantics (many possible models) and mod! if 
we wish to denote a module with tight semantics. Each module defines a sort 
(cither visible or hidden), the name of the sort defined is declared by enclosing 
it between [and ] in the case of visible sorts, and between * [and ] * in the 
case of hidden sorts. The definition of a module starts with its signature, the 
names of the sorts it defines, an ordering on them, and the set of operators on 
the sorts. In addition a module defines a theory on that signature, i.e. a set of 
equations constructed using the elements of the signature. An underscore _ in 
the definition of the operators indicates the place where an argument is put, for 
example _=_: Sortl Sortl -> Bool, declares that the equality operator will 
take two arguments and return a Boolean value (Bool is a built in module/sort 
for the CafeOBJ system) . Finally modules can be imported using the keywords 
pr( MODULENAME). 

An OTS is transferred to CafeOBJ in a natural way. Based on the hidden 
algebra approach, a visible sort denotes an abstract data type, while a hidden 
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sort denotes the state space of an abstract machine. On hidden sorts two kinds of 
operators can be applied; action operators and observation operators. An action 
operator is used to change the state of the abstract machine while we can only 
use observation operators to observe the inside of the machine. Declarations of 
observation and action operators begin using the keywords bop or bops, for the 
other operators we use the keywords op and ops. We define the operators using 
equations. The start of an equation is denoted with the keyword eq and the 
start of a conditional equation with the keyword ceq. The machine of CafcOBJ 
regards these equations as left to right rewrite rules and uses them to reduce 
complex expressions to simpler ones. The universal state space of an OTS, Y, is 
denoted by a hidden sort, say H. An observer Oi 1 ...i m <E O is denoted by a CafeOBJ 
observation operator. For the following we assume that there exist visible sorts 
14 and V denoting the data- types and D respectively with k = i\ . . . i m . The 
observation operator that corresponds to Oi 1 , m is defined in CafeOBJ as: bop 
o : H V n ...V lm - > V. 

Each member of the set of initial states of the OTS is denoted by a con- 
stant of the hidden sort, i.e., op init : -> H. Now suppose that the value of 
the observer Oi 1 .,.i m is F(x^ , . . . , a;, m ) in the initial state init, where Xi j are 
variables of the visible sorts Vi . . This will be expressed with the following equa- 
tion: eq o(init ,Xi r , Xi m ) = f (xi 17 ,Xi m ), where /(x^, is a CafeOBJ 
term denoting F(x il , , x im ). Each transition of an OTS Tj 1 ...j n 6 is denoted by a 
CafeOBJ action operator. Once again assuming visible sorts the CafeOBJ action 
operator that corresponds to the transition is define as: bop r : H Vj 1 . . . Vj im 
-> H. A transition rule (action operator) will successfully change the values re- 
turned by the observers if it is applied to a state where its effective condition hold. 
This is written in CafeOBJ notation as: ceq o(r(5', 

e-r (S , xj 1 , . . . , Xj m , Xi 1 , . . . , Xi m ) if c-t(5, Xj 1 , . . . , Xj m ). where S is a CafeOBJ 
hidden sort variable denoting an arbitrary system state, Xk are variables for the 
visible sorts Vk, also t(S, Xj 17 ...,Xj m ) denotes the application of transition rule 
Tj 1 ...j m to state S, i.e. the successor state of S and e-T(S,Xj 17 . . . , Xj m ,Xi 1 . . . x im ) 
is a CafcOBJ term denoting the value returned by the observer o il ,,, im in this 
successor state. Finally c — r(S,Xj 1 , . . . ,Xj m ) is a CafeOBJ term denoting the 
effective condition of Tj 1 ...j m . Let us point out here that the transitions do not 
change the values of the observers when the effective conditions do not hold. 

4 OTS/CafeOBJ to Java with JML 
4.1 OTS to Java Class 

The main constructs of a JML specification are JML invariants, constraints and 
finally requires and ensures clauses. JML allows the declaration of specification 
only variables on the form of ghost variables and model fields. Finally it is possible 
in JML to declare what a method is permitted to affect using Frame properties 
and the assignable clause. In this section we will use the above to provide an 
implementation of an Observational Transition System (OTS) in JML. This 
translation will ensure that the properties proved for the OTS will still hold for 
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the Java implementation. This is achieved because the Java implementation has 
to comply with the JML specification when using the jmlc compiler or can be 
statically verified using the various tools. In this subsection we will consider only 
the case of one OTS that will not contain other OTSs. For the following definition 
we assume that there exist predefined data-types in Java, either built-in or user 
defined, for the corresponding abstract data-types of the corresponding OTS. 
As an OTS can be regarded as a type of black box so does the corresponding 
generated Java object 'hide' from us its full state and allows us to characterize 
it only by the use of pure methods, that correspond to the observers. 

Definition 1 

Given an OTS S =< 0,I,T > we define an implementation of S in Java/JML 
as a Java Class S such that: 

— For each observer oi S O we define a pure method o Pi such that if o : 
Y x D Ql x ... x D 0m — > D Q then the signature of o Pi will be: public /*@ 
pure @*/ D o Pi (D 0l di, . . . , D Qm d m ) . 

— For each initial state Ui n u 6 / , we define a Constructor method Cui n it(), 
such that if o(v,i n it,yi, ■ • ■ , y n ) — Vo init then Cui n it() is JML annotated with 
no requires clause and in the post-condition for all observers we add clauses 
of the form//® ensures o Pi (yi , . . . , y n ) == y 0init ', 

— In addition we define a Behavioral Equality method. This is a method public 
boolean equals (S another) ,and is annotated with JML code that ensures 
that if all the observers for two objects are equal then they are considered 
equal. So for each observer method o Pi of the class S the following annotation 
is added: //@ esiLsures\forall(D 0l di . . . D 0m d m ; this. o Pi {d\, ... ,d m ) == 
another. o Pi {d\, ... ,d m )) => \result == true ; 

— Also we define a Deep Copy constructor, with signature public S (S another) . 
This is annotated with a requires clause //@ requires another != null, 
stating that the object to copy cannot be null. Also this constructor en- 
sures that the observers of the two objects will be equal and that the 
object created and the object copied will not point to the same place in 
the memory. These are defined with the following JML code: //<§ ensures 
\forall(D 0l di . . . D 0m d m ; this.o Pi (di, . . . , d m ) == another. o Pi (d\, . . . , d m ) 
&&...&& this. o Pk (di, ... ,d m ) == another. o Pk (d\, ... ,d m )) && (thisl = 
another); 

— For each r, G T, T{ : YD tl D tn — > Y, we define a method with signature: 
public S Ti(D tl Xt 1 D tn Xt n ). Also in the body of the method we have 
a local ghost variable to store the pre-state of the object 0. This is achieved 

1 this is necessary because the \old JML command only stores the pointer to the 
object in the pre-state and not the object it self. We believe that this technique is 
acceptable since the impact of object creation is often overestimated, and can be 
offset by methods like garbage collection, etc. [31]. Finally note that the ghost field 
could be as easily been implemented as a regular variable/object, however we prefer 
to produce as little implementation code as possilbe here 
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using the deep copying constructor we defined above and an annotation like 
//@ set ghost S temp = new S(this) ; . This method is also annotated 
with two JML contracts: 

1. For the first contract, in the "requires clause" we have a set of statements 
that define the conditions under which the effective condition of the 
transition rule c-n, holds (using the pure methods that correspond to 
the observers). Also in this contracts ensures clause we define: 

(a) that the result of the method is the new state of the object, //<§ \ 
result == this ; 

(b) In the post-condition for each observer o n € O such that o n (ji(u, , . . . , 
yi,...,yk) = y n the following is added //Oensures o Pn (yi, . . . , Vk) 
== TJn ; ■ If for y n a reference to the pre-state is necessary that is 
made using the temp ghost field. 

2. The second contract contains in its requires clause the statements nec- 
essary to make c — false and an assignable clause that makes certain 
that the call of the method in a system state that does not satisfy the 
effective condition will not change the state of the system. This can be 
defined ao //@ assignable \nothing; 

An example of this translation is given in table 2, where the specification in 
OTS/CafeOBJ and the corresponding translation to JML/Java of a simple bank 
account system is given. The OTS/CafeOBJ code was taken from [19]. 

4.2 Multiple OTSs to Multiple Objects 

In real life applications it is highly unlikely that an object orientated program will 
require the use of only one object. Usually multiple objects will work together 
to produce a single application. This feature is already covered in the behavioral 
specification paradigm. In such techniques reusability is a key feature. In object 
orientated programming reusability of the source code is the goal while in object 
oriented specification, the ability to be able to reuse both the code and the proofs 
is desired. In their paper [19] the authors provide ways to reuse code and proofs. 
Their approach is compositional. The key technical construct that allows this 
reusability is a special type of observer, the projection. The formalism in [19] 
is done via Hidden Algebra [22]. Here for uniformity we will continue using the 
OTS/CafeOBJ formalism since the relation between OTSs and Hidden Algebra 
is well established and the interchange here does not cause problems. 

In order to define an object composed by a set of other objects, we must define 
for each composing object a projection operator to get their states from the state 
of the composed object. These operators are subject to several mathematical 
conditions which are formally defined in [19]. Their essence is as follows [19]: 

1. all transitions of all components are represented by transitions at the level 
of the compound OTS via these projection operators 



2 another way to model this would be as an expepsional post-condition. 
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OTS/CafeOBJ 

mod* ACC0UNT{ 
pr(INT) 

* [Account] * 

— initial states 

op initAcc : -> Account 

— observers 

bop money : Account -> INT 



— transitions 

bop add : Account INT -> Account 

op c-add : Account INT -> BOOL 
var I : Int 
var A : Account 



eq c-add(A,I) = read(A)+I >= . 

eq read(init) = . 

ceq read(add(I , A) = I + read(A) if 

c-add(A.I) .} 



JML/Java 

public class Accountj 

//@ public ghost Account temp; 

//(§ ensures balance () == 0; 
public Account (){} 

public /*© pure @*/ int balance () {} 

/*@ requires this. balance () + x >= 
j 

@ ensures (\result .balance () == 
temp. balance () + x) &&: \result = 
this ; 
@ also 

@ requires this .balance ()+x < ; 
@ ensures \result .balance () == 
temp. balance () && \result = this ; 
©*/ 

public Account add(int x) { 

//@ set temp = new Account (this) ; } 

//@ ensures (this .balance () == 
ac2 .balance () ) ==> (\result == 
true) ; 

public boolean equals (Account ac2) 
{} 

//@ requires another != null ; 
//@ ensures (this .balance () == 
another. balance ()) && (this ! = 
another) ; 

public Account (Account another) {} 



Table 2. Simple bank account system in OTS/CafeOBJ and JML/Java 



2. each observer of the compound object is related via the projection operations 
to an observation of some component and finally 

3. each constant state of the compound object is projected to a constant state 
on each component in the compound objects. 

Note that the previous intuitive definition implies that we have a fixed num- 
ber of composing objects. The first characterization of this kind of composition 
is concurrency. In order to define concurrency we need the notion of a method 
group. The authors of [21] define that two transitions of a composed object be- 
long to the same method group when they are related to the same composing 
object. Concurrent connection is now defined as the case where if we take two 
transitions, which belong to different method groups, the order of application 
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of these does not change the reached state. Synchronized concurrent connec- 
tion now is defined as the case where we have partial concurrency between the 
composing objects. Synchronization happens when either the projected state of 
a composing object is depended on the state of another composing object or 
when the transitions of the composed object change simultaneously states of 
several composing objects. A first result of this is that behavioral equivalence 
in composed objects is a conjunction of all the behavioral equivalences of the 
composing objects [21]. 

Static systems are a special case of Dynamic systems. In the latter the config- 
uration of the system may change through the execution of the transitions. This 
is covered by allowing identifiers to manage object creation and deletion, i.e. 
parameterizing the projections. In [21] the authors define that a dynamic object 
can be created or deleted in a composed object and its initialization is handled 
via object identifiers. These operators conform to the conditions given above as 
well but in addition a projection operator for a dynamic object has an object 
identifier in its arguments. A second result of the paper is a refinement of the 
first and states that for the case of dynamic systems the behavioral equivalence 
of a composed object is a conjunction of all the behavioral equivalences of the 
composing objects [21, 19]. 

In OTS/CafeOBJ notation a parametrized projection is defined as, ir : ID Y — > 
Y n , where Y is the state space of the composite object, Y n is that of the Class n 
composing objects and ID is a set of identifiers for them. This is transfered to 
JML/Java as a parametrized pure method that returns Class n objects. 

Definition 2 (Projection Methods) In order to retrieve the state of a Class n 
object we define a pure method, with signature public /*<§ pure 0*/ Class n 
getCn (int i){} , that is annotated with the following JML contract 

/*@ public normal_behavior 
@ requires (i >= 0) ; 
@ ensures (\forall int j ; 

@ ( ((getCn(i) != null) kk (i !=j)) ==> getCn(i) != getCn(j)) ) ; 
@*/ 

Before continuing we have to update the definition of the deep copy construc- 
tor so that it correctly copies the composing objects. For each class of composing 
objects Cn we add to the contract of the deep copy constractor from definition 
1 the following annotations: 

@ ensures (\forall int i; (this . getCn(i) ! = null) ==> 
@ this . getCn(i) . equals (another .getCn(i)) kk (this . getCn(i) 
!= another .getCn(i)) ; 

For the following we assume that all base level objects we will use contain 
the equality and deep copy constructor methods we specified in definition 1. 

3 This ensures that when the objects returned by the projection exist, they are different 
objects and not just different references to the same object. 
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Bullet two, of the informal definition states the each observer of the composite 
object is equal to the composition of projections and chains of actions, obser- 
vations of a component object(s). By denoting with ch n the chains and by / 
the composition, for an observer o of the composite object in OTS/CafcOBJ 
notation a composite object observer will be defined by an equation of the form: 
o= (TTi;ch nil . . . ,T: k ;ch nk )f. 

Definition 3 (Composite Object Observers) The previous composite object 
observer is defined in JML/Java as a pure method o with a signature public /*@ 
pure @*/ D a o (Diyi, . . . D n y n , int idi,..., int idk){ //@ set temp = new 
S(this) ;} that is annotated with the following contract: 

\*@ requires this . getCl (idl) != null 
&& . . . 

tt this.getCk(idk) != null ; 

ensures \result == f (temp . getCl (idl) . chnl () , 

temp.getCk(idk) .chnkO) ; 

<§*/ 

Where chniO are Java terms that correspond to the chains ch ni . Note that 
we must take extra care to ensure that the transition calls inside these chains do 
not change the actual states of the composing objects. This is why it is necessery 
to use the ghost field temp. 

Before we give the definition of the transitions in a composite OTS we must 
update the behavioral equality method (equlas) so that it takes into account 
the projection methods. So we define that for all projection methods getCn the 
following term is added to the contract of the method: 

//@ ensures (\forall int i; this .getCn(i) . equals (another .getCn(i) ) ) ; 

Bullet three of the informal definition states that, for each transition of the 
composite object r and each composing Class n object, c ni there exists a transi- 
tion of the compoment object r ni such that for state u of the composite object 
t(u); Tr ni — 7T„ j (u); r ni . This is expressed in JML/Java with the following defini- 
tion. 

Definition 4 (Composite Object Transitions) At the first line of the body 
of the method we store the pre-state of the object in the ghost field temp. For each 
object, c ni , who's state is change by the transition we add in the requires clause 
of the contract: //<§ requires this . getCn(i) ! = null. Finally, the ensures 
clause for each such object we add: //@ ensures this . getCn(i) . equals (temp . 
getCn(i) .T ni (. . .) ;). 

In the dynamic compositional paradigm, the dynamic compound objects 
might add new actions which do not correspond to actions of the components. 
More over if we wish to handle a variable number of component objects two 
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transitions are madantory in order to define the insertion and deletion of ob- 
jects. In most casefQ the signatures of these methods will be add : Y ID — > Y 
and delete : Y ID -4 Y. 

Definition 5 (Adding and deleting components) The composite object tran- 
sition that adds a new Class n component to the configuration of the system is 
defined having a signature public S adddnt id){} and is contracted as: 

/*@ requires this . getCn(id) == null; 

@ ensures \result .getCn(id) . equals (new Account () ) && 

@ (\forall int j ; (j != id) ==> \result .getCn(id) != \result .getCn(id) ) 

@ \result == this; 

<§*/ 

Also composite object transition that removes a component object from the 
configuration of the system, has as signature : public S deldnt id) {} and 
is contracted as: 

/*@ requires (this . getCn(id) ! = null) ; 
@ ensures \result . getCn(id) == null && 
@ \result == this; ; 
@*/ 

To clarify all these definitions the previous example of the bank account is ex- 
panded in Appendix A, to a bank system where accounts are created and deleted 
dynamically and the users can add are withdraw money from their accounts. 
First we give the code in OTS/CafeOBJ notation and then the corresponding 
JML/JAVA code0 

4.3 Inheritance 

One of the most attractive features of object orientated programming is in- 
heritance. Observation Transitions Systems are a proper subclass of behavioral 
specifications. The semantics of behavioral specifications are those of hidden al- 
gebra [22, 15]. When it comes to defining inheritance in the OTS framework it is 
more convenient to talk in terms of hidden algebras rather than OTSs. The state 
space of an object is represented as a hidden sort. In hidden algebra there exist 
two kinds of sorts. Visible sorts that represent the data part of the specification 
and hidden sorts representing the states of the objects. A hidden signature of 
an order sorted algebra is defined as (S, <, E) [19], where S is a set of sorts and 
£ is the set of operators on S, also we consider H C S, , the hidden sorts. The 
visible sorts, V, are defined simply as S \ H . In the above (S, <) is a partial 

4 allthough more parameters might be required depending on the situation, for sim- 
plicity we assume that only the hidden sort and the is required here 

5 all examples were implemented with the open JML plugin for eclipse, 
http : / /sourceforge .net /pro j ect s/jmlspecs / 
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order set. An operator is denoted as a : w — > s, , where w G S* and s £ S. We 
call the input of a, w, the arity of the operator and the result, s, the co-arity. 
Now given such a signature a model of it interprets each sort s G S as set A s , 
each subsort relation s < s' to an inclusion A s C A s > and finally each operator 
a G i7si,...,s n ,s t° a function A a : A Sl x ... x A Sn — > A s . In hidden algebra, 
inheritance is modeled via subsort relations [15]. This means that the space of 
states of the inheriting object is included in the space of states of the inherited 
object: enabling the inherited methods to act on the states of the inheriting 
object. In OTS notation the previous definition would mean that if we wish to 
denote that S =< 0,I,T > with the state space Y, is inherited by the OTS 
S' =< 0',I',T' > with the state space Y', then we must define that Y' C Y . 
Such a specification would be translated into Java/JML by simply stating that 
the class that corresponds to the OTS S' extends the class that corresponds to 
the OTS S. 

5 Conclusions 

We have presented a translation between the OTS/CafcOBJ specifications and 
the JML/Java specifications. The goal of this was to allow for the specification 
and verification of the design of systems in OTS/CafeOBJ and at the same time 
guarantee that the Java implementation complies with the specification using 
the tools of JML. This approach allows us to use in our opinion the best of both 
worlds and accomplishes to overcome some of the shortcomings. In the future 
we will build tools that automatically translate an OTS/CafcOBJ specification 
to a JML specification to facilitate this process. Also similar translations and 
tools must be defined for other DBC specification languages, so that the various 
components of a large system that are implemented in various programming 
languages will comply with the original specification in OTS/CafcOBJ and thus 
enjoy the desired verified properties. 
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6 APENDIX A 

mod* ACCOUNT-SYSTEM { 
pr (ACCOUNT) 

*[ AccountSys ]* 



op init-account-sys : -> AccountSys — initial state 

bop add : Uld Nat AccountSys -> AccountSys — method 

bop del : Uld AccountSys -> AccountSys — method 

bop deposit : Uld Nat AccountSys -> AccountSys — method 

bop withdraw : Uld Nat AccountSys -> AccountSys — method 

bop balance : Uld AccountSys -> Nat — attribute 

bop account : Uld AccountSys -> Account — projection 



vars U U : Uld 
var A : AccountSys 
var N : Nat 



eq account (U, init-account-sys) = no-account . 

ceq account (U, add(U, N, A)) = add(N, init-account (U) ) 

if U == U . 

ceq account (U, add(U, N, A)) = account (U, A) 
if U =/= U . 

ceq account (U, del(U, A)) = no-account 
if U == U . 

ceq account (U, del(U, A)) = account (U, A) 
if U =/= U . 

ceq account (U, deposit (U, N, A)) = add(N, account (U, A)) 
if U == U . 

ceq account (U, deposit (U, N, A)) = account (U, A) 
if U =/= U . 

ceq account(U, withdraw(U, N, A)) = add(-(N), account(U, A)) 
if U == U . 

ceq account (U, withdraw (U, N, A)) = account (U, A) 
if U =/= U . 

eq balance (U, A) = read(account (U, A)) . 
} 
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public class AccountSYS { 

private ArrayList<Account> accounts ; 
//(§ public ghost AccountSYS preObj ; 

//Oensures (\forall int i; this . getAcc (i) == null) ; 
public AccountSYS (){ } 

// Deep Copy Constructor 
/*(§ public normal_behavior 
@ requires another != null ; 

ensures (\forall int i; (this .getAcc (i) ! = null) ==> 

(3 (this .getAcc(i) . equals (another .getAcc (i) ) kk 

(this .getAcc(i) != another .getAcc (i) ) 

kk (this.getBalance(i) == another .getBalance(i) ) ) ) ; 

*/ 

public AccountSYS (AccountSYS another) { } 

// 1. Projection OPERATOR 

/*@ public normal_behavior 
requires (i >= 0) ; 
ensures (\forall int j ; 

( ((getAcc(i) != null) kk (i !=j)) ==> getAcc(i) != getAcc(j)) ) ; 
<§*/ 

public /*@ pure @*/ Account getAcc (int i) { } 

// 3. EVERY OBSERVER IS REPRESENTED BY AN OBSERVER AT THE COMPOSITE OBJECT 

//@ requires this . getAcc (id) != null ; 

//@ ensures \result == this. getAcc (id) .balance () ; 

public /*(§ pure @*/ int getBalance (int id) { 

//<§ set preObj = new AccountSYS (this) ; 

} 

//2. ALL TRANSITIONS ARE REPRESENTED BY TRANSITIONS IN THE COMPOSITE LEVEL 

//<§ requires (this . getAcc (id) != null) kk (n >= 0) ; 

/*@ ensures \result . getAcc (id) .equals (preObj .getAcc(id) .add(n)) 

kk \result == this; 

@*/ 

public AccountSYS deposit(int n, int id){ 
//@ set preObj = new AccountSYS (this) ; } 

//<§ requires (this . getAcc (id) != null) kk (n >= 0) ; 
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//@ ensures \result .getAcc(id) . equals (preDbj .getAcc(id) . add(-n) ) 
@ kk \result == this; ; 
<§*/ 

public AccountSYS withdraw(int n, int id){ 
//<§ set preObj = new AccountSYS (this) ; } 



// Extra Composite Level Transitions 
//@ requires this . getAcc (id) == null; 

/*<§ ensures \result . getAcc (id) . equals (new Account () ) kk 

@ (\forall int j ; (j != id) ==> \result .getAcc(id) != \result . getAcc (id) ) 

&& \result == this; 

<§*/ 

public AccountSYS add(int id){ 

//<§ set preObj = new AccountSYS (this) ; } 



//@ requires (this . getAcc (id) ! = null) ; 

//(§ ensures \result . getAcc (id) == null kk \result == this; 

public AccountSYS del (int id) { 

//@ set preObj = new AccountSYS (this) ; } 

} 



